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(57) In a cryptographic system, a device is manu- 
factured with a secure section that generates an internal 
secret. An irreversible cryptographic transform of the in- 
ternal secret is created and a certificate containing the 
irreversible cryptographic transform and a unique iden- 
tifier of the device is signed using a manufacturer key. 
The device and the certificate are provided to a network 
operator. An initialization process is performed under 
the control of the operator to set up a secure channel 



between two devices under the control of the operator 
for secure communications between the two devices. 
Because of the internal secrets maintained within each 
device and the certificates, the devices can authenticate 
each other and communicate securely, even over an in- 
secure channel, without needing the devices to have 
been previously programmed with a secret of the oper- 
ator. The devices can authenticate each other and cre- 
ate a shared secret, all over an insecure channel. 
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Secure communications has several charactenst.es. One cha ~ ,c recipient . Another characteristic 

or a communication error. ^ m ..nications a message could be rendered readable or alterable 

10003] Ofcourse,wnhmostrealizablese^ 

Smenoughtime. effort and computing power, ^^^^^hlhav^g a decoding key for the m^ge 
or unalterable if an attacker could not read or alter the message w.tno message to read .ts contents 

or expend^ more than a threshold amount of designed so that the threshold amount 

o , ocreateanaltered message. Typically secureco^—^^ 

o limtt the use of a communications or data storage ^ sys em secu ^ & ^ (q a destlna(lon in . 

'communications system" is used to, ret er to. ^^S™^s.ems, or transfers data to and from data 
c.uding those systems not tradit.ona.ly ^^SSS from the data writer to the data reader), 
storage in a secure manner (i.e.. secunngthe C0 T U T^L^ system keeps those messages secret and ,s 
S securing one or more messages. ^^S^^ course, some cryptographic systems 
also used to ensure authentication, integrity and nonrepudiat, or « ™J» documents are authent.cated but 

S not do al, o. those functions. For example, on^ 
Suthenticateddcx.umentsareopenforal.v.ewe^sto^ 

St:— .cationssystemsdesigns,^ 

secure access. .nmmunications channel. One use is for encrypting and decrypting 

[0007] Keys have several uses in secunng a c °~" so ^ e to a destination is assumed to be 
messages. In such a use, channel used to ^^^Xptng attack' where an attacker listens to traffic 
40 Tome way An insecure channel might be subject to «»J^™2o be subject to a -man-in-the-middle" attack 
n^rom the source to the destination. An \^^X^^^^ m ^ mtV ^ 

,he security measures added by the svs,e ™ des ' 9 " mQre difficutt by encrypting the traffic from the source to the desti- 
10008] These attacks can be made considerably "™^2Z& anyone in possession of the message)* 
nation With encryption, a plaintext message ^™°^™ eyA J not easily converted back to the plaintext 
converted to a ciphertext message us,ng a ^. t ^^^L am process with the plaintext message and a 
50 message without knowing the key. B^J^J ^^JTdoes not rely on the attacker being unaware o 

Key as inputs to the process- ^ZlTemZ^^ » * ^ *" *" enCrVPti ° n " 
the details of the encryption process. In better cryp «a h ' , he attacker . 

entirely known and security is only provided ^^J^^^m can be illustrated with reference to a 
?0009] The usefulness of each of the above face s of secure «mmu tQ g sa , e belween 
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communications, so an eavesdropper or putative thief (genetically referred to as an "attacker* in many cryptography 
texts) cannot read or undetectably modify the message traffic without knowing a message key. 
[001 0] As should be apparent, the parties involved in a sales transaction want the message traffic to have the above 
aspects of secure communications. The customer wants to ensure that the communication is secret, so that his or her 

5 account number is not readable by an attacker. The bank wants to ensure that the communications is authentic so that 
funds are only withdrawn when duly authorized by the customer. The integrity of the messages needs to be ensured, 
so that an attacker cannot edit a message to replace the merchant's account number with the attacker's account 
number. Nonrepudiation is also important for the customer's bank because the bank does not want to be in a position 
where they have paid the merchant for goods the customer took away from the point of sale but the customer repudiates 

10 the transaction and wants the transaction to be backed out of his or her account. 

[0011] Each of these facets of secure communication can be assured if the bank and the customer take steps to 
secure communications between the customer and the bank. Since the bank is more likely to be involved in setting up 
the infrastructure than the customer is, the customer's involvement in security is typically limited to selecting a password 
(a 'key") and keeping the password secret. While the customer's task is a simple matter of memorizing a key, the 

is bank's task is much more complex since there are many opportunities for an attacker to intercede in the communications 
to make it insecure. The risk is also much greater for the bank than the customer. If a customer's security is breached 
and an attacker obtains the customer's password, the attacker's take is usually limited to the funds available in that 
one customer's bank account. The take may be further limited if the customer notices the unauthorized activity in 
process. However, if the bank's security is compromised, the attackers take is not so limited and is not so noticeable. 

20 Because of this, the bank has great interest in having a secure system. 

[0012] If public key encryption is used, a pair of keys is generated with one of the keys being a private key and the 
other being a public key. In either case, a secure terminal contains secret keys. If an attacker is able to obtain those 
secret keys, the attacker may be able to listen in on message traffic to and from the secure terminal and may even be 
able to intercept the traffic. In some cases, the attacker knowing the secret keys might have enough knowledge to 

25 modify a message destined for the secure terminal and modify corresponding messages being sent by the secure 
terminal so that the attacker could continue to alter later message traffic without detection. Such a compromise could 
continue even after the secret keys were changed, if the attacker intercepts the messages containing a "change key" 
command and the new secret keys. 

[0013] Because of the continuing access, a compromised terminal will remain a compromised terminal. Conversely, 
30 a secured terminal will usually be able to remain a secure terminal, if designed properly. Once a secure system is 
compromised, it cannot be considered a secure system. Therefore, the secure system needs to be secure at every 
step of implementation, including the first installation of the system. One difficulty with the first installation is that the 
terminal needs to start with an initial set of secret keys. The initial set of secret keys can be changed remotely, by 
sending the terminal a secured command message with the new keys and instructions to change the keys. If the 
35 terminal is compromised before the "change keys" message is sent, then it is possible that the attacker could read the 
message and update its copy of the keys, thereby continuing the compromise. In light of the above vulnerabilities of 
cryptographic systems, the design of an initialization process for cryptographic devices must be done carefully for the 
devices to be secure. 

[0014] One solution for device initialization that has been used is to install an initial set of keys during manufacture. 

40 a disadvantage of this solution is then the manufacturer would have to keep track of the initial keys for each device 
and the purchaser of the terminal would have to rely on the manufacturer to keep that information secure. If the initial 
keys are loaded in the clear, then anyone monitoring the process can capture the keys and compromise the security 
of the device. Alternatively, the manufacturer might produce the devices so that they all have a common initial key 
While the common initial key would allow for initial, unique, key loading secure from casual eavesdroppers, the security 

45' of a key common to many devices is doubtful. 

[0015] Another method of device initialization is the "trusted agent" approach. With this approach, a cryptographic 
system is manufactured without keys and is initialized by a trusted agent of the owner of the cryptographic system by 
entering the key into the cryptographic system over a secure channel. If the cryptographic system is located on a 
remote network connected by insecure connections (such as the global Internet), then the trusted agent would have 

50 to travel to the location of the cryptographic system to enter the initialization key. Typically, one employee of an agent 
is not entirely trusted, so the initialization key will be divided among two trusted employees of the agent, who will each 
travel to the cryptographic system location to enter their respective portions of the-initialization key. This, of course, is 
expensive and time-consuming. Furthermore, if dedicated hardware, such as a key entry keyboard is used, it adds to 
the cost of the device and prevents automated key loading. 

55 [0016] The trusted agent approach is currently used for loading the initial keys into new ATM's (automated teller 
machines) and POS terminals (generically referred to herein as "terminals"). At least two security personnel who provide 
dual custody of DES key parts supervise the actual loading of keys from a key-loading device to the terminal. This key 
loading process is particularly burdensome in the case of debit POS terminals, as a typical network may have tens of 



3 



EP 1 081 891 A2 



10 



15 



thousands of such terminals. . . d ^ js a seC ure location where all of 

0017] To avoid trave. to remote « keys are loaded into cypt. 

the cryptographic systems are brou^ 

must be maintained and several extra tra ^^^£?the present invention, a device is manufactured 
[0018] in a cryptographic system accord ng to ^^^^ptographic transform of the internal secret 
with a secure section that generates an mtemal ^^^^SmZ a unique identifier of the device is 
is created and a certificate containing the V^^SSSS^!^ * a network operator. An initialization 
signed using a manufacturer key. The channe. between two devices under the 

process is performed under the ^^L^S^^dowices. Becauseof the internal secrets maintamed 
control of the operator for secure communicat-ons between the » woo comrnunicate securely, even over 

within each device and the certificates the dev«=es ^^^1^^ a secret oi 
an insecure channel, wrihout needing the ^^TJ^^^^er an insecure channel. 

20 with a secure section. ^« rtri ^ f c in o shown in Greater detail. 

an embedment of a security module according to of a sec J nly modul e is used repeatedly as an 
described. Furthermore, in this descnption, { ^^e^Toio, M skill in the art, so the invention should 
examp.e. Other applications and varans «tt b J ! ^^ tMI appended 
not be construed as narrowly as the f^^^^^SjiiB system is the use of the security modu.es 
[0027] One specific application that is used repeatedly .n describing tn y o{ ^ funds and cus . 

L^nktocontro. messages between the confidential, authentic and 

tomers, wants to ensure that funds transfer m *^f^ 

intact. Beingastrongguardianof «sdeposrtors to modify the traffic to read confidential 

or the bank's employees not \™^Zl?^^^™etce#<x has no authority over, 
messages or to cause funds to be transferred ^ ™ or other securrty ^inded entity is system 

[0028] One example of a computer system that ^^^ a ^ tMk ^. In this description, 'manufac- 
ioshown in Fig. 1. In system 10, .various d ~.^~ 
turerNs used to describe the ent,^ 

essarily trust the manufacturer. understood that the present invention is not limited to 

[0029] Network 12 is an untrusted network, but ,t should be under* oofl mat tn P rk o1 nelworks 

use 1 an untrusted networ, One IhaUhe routing of packets is generally 

generally known as 'the Internet-. The ^^^XTertcSnpuler systems unknown to. and uncontrolled by, 

Sh=^^ 

manager (SKDM) 16. the operation of wj.chis f^^T^Zl network^. Mhough such unauthorized 
ized terminal K and an unauthonzed SKDM 116 are shown ^c archtte cture and components of the 

with the authorized equipment. 
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[0031] Fig. 2 shows one embodiment of terminal 14 in greater detail. While Fig.. 2 is a block diagram of terminal 14, 
it should be understood that SKDM 16 could be constructed in a similar manner. Terminal 14 is shown comprising an 
input/output (I/O) section 20, a terminal-specific logic block 22 and a security module (SM) 24. In a typical setup, the 
operator of the terminals purchases the terminals from the manufacturer and installs them onto network 12 for use by 

s the operator for some purpose specific to the operator. 

[0032] Security module 24 is shown comprising a secure section (SS) 26 and an unsecured section 28. A well- 
designed secure section has several properties common to well-designed secure sections, such as a tamper-resistant 
boundary. A tamper-resistant boundary makes is difficult for an attacker to get at the internal elements of the secure 
section without at least leaving clear evidence of a breach, such as a broken wire, an erased memory, or the like. 

10 Another property is that the secure section has tamper detection mechanisms to detect when penetration is in progress 
and erases or destroys secrets before the penetration is complete and the attacker obtains access to the secrets. 
Furthermore, a well-designed secure section is logically secure, in that no set of signals, data inputs or commands 
exist that would cause the secure section to release any of the secrets protected within the tamper-resistant boundary. 
[0033] Unsecured section 28 contains logic and data that supports the operation of security module 24 but that need 

15 not be kept secure, such as an I/O interface between SS 26 and the rest of terminal 14. Both secret and nonsecret 
data elements can be stored in SS 26, but it might be preferred to keep them separate so that any extra logic needed 
to secure a memory against reading need only secure the secret data elements. 

[0034] Fig. 3 is a block diagram of SS 26 in further detail. As shown there, SS 26 includes section I/O 30, process 
logic 32 (such as gates or a microprocessor), storage 34, a random number generator (RNG) 36 and an exponentiator 

20 38. The details of the data stored in storage 34 are described below in connection with various processes performed 
by SS 26. As is well-known in cryptographic system design, some security operations rely on random numbers and 
exponentiating values, so an attacker could defeat the security of a system by controlling or observing the random 
numbers generated by RNG 36 and the exponentiation performed by exponentiator 38. Therefore, a random number 
generator (RNG) 36 and an exponentiator 38 are preferably secured within the tamper-resistant boundary of SS 26. 

25 [0035] The process of putting a terminal into operation will now be described. Since the initialization of terminal- 
specific logic block 22 depends on the specific use of the terminal and that is outside the scope of this description, the 
focus is on the initialization of a secure section 26. The initialization of SS 26 is described here in two parts. The first 
part details the operations that are done by the manufacturer of SS 26, while the second part details the operations 
that are done by or for the operator of SS 26. 

30 [0036] An SS manufacturing process is illustrated in Fig. 4. In the manufacturing environment 100 shown, a manu- 
facturing initialization facility (MIF) 110 comprises a manufacturing workstation (MWS) 11 2 that is part of MIF 110. MSW 
112 is coupled to a manufacturing installation security module (MISM) 11 4 that is secure within MIF 110. MIF 110 also 
includes a manufacturing database 116 that contains data about security modules that have be initialized by MIF 11 0. 
[0037] A target SM 124 having a target SS 126 is shown coupled to MIF 110 via a link 120. In the process described 

35 below, target SM 124 is the SM being initialized. Link 120 need only be secure from data tampering, i.e., data sent 
from target SS 126 to MWS 112 is received by MWS 112 unaltered and data sent from MWS 112 to target SS 126 is 
received by target SS 126. Link 120 could also be secure from eavesdropping, but that is not necessary to maintain 
the overall integrity of the initialization of target SS 126. 

[0038] Prior to the initialization process, target SS 126 can be generic, i.e., individual target SS's 1 26 are identical. 

40 Target SS 126 becomes nongeneric as a result of the initialization process carried out by MIF 110. The details of one 
such initialization process are illustrated in the circled numbers in Fig. 4 indicating a set of ordered steps. Corresponding 
numbers are included in parentheses in the text below near the steps that correspond to the circled numbers. 
[0039] To start, the MIF generates a serial number, SSID, for the target SS and passes SSID to the target SS (step 
1). The target SS stores SSID (2) (in its storage 34; see Fig. 3) and generates a public key pair KSS (3) and stores 

45' the key pair in its storage 34. KSS comprises a private part KPVSS and a public part KPBSS. The generation of KSS 
can be triggered by the receipt of SSID., the receipt of a command from the MIF, or some other suitable trigger. Once 
the target SS generates KSS, it sends the public part (KPBSS) to the MWS (4). As part of the overall security of the 
system in which the target SS is installed, the private part KPVSS remains within the target SS and does not ever need 
to be communicated outside the target SS. 

50 [0040] The MSW provides KPBSS and SSID to the MISM, which generates a manufacturer certificate, MCert. The 
manufacturer certificate contains KPBSS and is signed by an MIF private signature key, KPVSIGM, maintained within 
the MISM (6). The MISM is initialized with the MIF signature key pair (KPVSIGM, KPBSIGM) before any SS's are 
initialized by the MIF. The manufacturer certificate might also contain other data elements, such as SSID, the certificate 
version number, device permissions (for the target SS) and algorithm parameters (to be used by the target SS), the 

55 uses of which are described below 

[0041] The manufacturer certificate is then passed from the MISM to the target SS for storage at in the target SS 
(7), along with the MIF's public signature key, KPBSIGM, which is also stored within the target SS. The MIF also 
generates a verification certificate 1 30 containing SSID and a copy of MCert (8). 
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[0042] A t .ispo,,.e,a^SSis r V Tr ^^ ^^^^SSSS 
SSID . but it is typical* not specific to the ^J^g££^m»m *» each operator. Either 
be specific to an operator by using a different MIF this ^ what follows is a description of an 

way the targe, SS preferabty does no. : oart^ ^^^SSZ*» "P"*"- set Up 
initializatton process that configures ^^^tS operator is provided with the verified certBicate 130 
[0043] When the target SS is provided to the ^erator tfiatop n ^ ^ ^ ft fe p(eferab|y 

hat goes wfth the target SS. Tne venficaton allows the operator to verify that the target 

provided under separate cover to the ^^^SS!Sm «d •» be en initia " Zed bV ^ Th' 

SS delivered under separate cover ® ^ gg ^ gS into an SM 24. Alternatively, the manufacturer could 

plo^eS 
?r/once»eope ra to™ 

The operator typically will run one or more SKDM s ss , rQm the SKDM. One of the security 

operator secrets, such as key load.ng keys nltay J^J^^ termina , „■ and that an SS not accept 
concerns of the operator is that the .SKDM m* toad keys™™ ^ ^ ^ authenticate ^ 
commands and keys from an ^ a ^'^^ {t ^^ be US ed to compromise operator secrets. 

prior installation ot an operator secret m the *»■ used between ^ devjces operated 

[0046] One example of a specrf.c mutua I authent t J p(ocess sh own in Fig. 5 will be apparent to 
by the operator is shown in the flowchart of Fig. *^T£2£t of Fig 5 are numbered beginning with step S 
those o« skill in the art from this description The ^^^^ the steps are performed in the numbered 
1 and those numbers are used in the text betow £J^^2?^^c«vi^a 
order.butoneotskillintheartwillnotef^ 

one step does not require that a smaller numbered I st p be *™ ™£ 9 nd devfce B t0 each othe r and results 
t 0047] The process described in Fig. R «M* <» computing power or time, the shared 

30 n a shared secret known only to dance A and I dance B. Of course g ^ ^ ^ ^ computing 

secret could be obtained by an attacker, so the design d he system ^ ^ ^ 

power or time is high enough to make "J^J^^^'SL authentication process. Another advantage of 

35 authority and a certificate chain ^"^J'f f (of ^ precisely , , he SM 24 of one of those devices). Device B 

40 Ltion (step 81 )• Following the ^^g^^^^ * manufacturer certificate for device A 
such as a unique identifier (labeled IDA in F.g. 5), an ^"J?^~L^ section 0 , de vice A and never needed to 
MCert A ). Note that the interna, secret KPVA two messages, Ml and M2. and 

be disclosed outside that secure section, even J ^^S?Sj>SbA1 . signed by KPVA 
sends those messages to device a Message ™ £ ushg KPBSIGM. the manufacturer public signing 

45 [0050] Once device B receives M1 and M2, device B venf.es * us ,j unauthorized dev.ee. 

ley ik If M2 does not verjy, device o, which KPVA is the private par,. As 

Device B then extracts KPBA from M2 (S3) "J^J^Sr certificate. At this point, device B .s reasonably 
explained above, that pub.ic part was ^ ™ u ^e manufacturer certfied it. 

assured that KPBA is in fact the put* .part £ me key. because me g ^ process and , 

50 [0051] A, step S4. device Bvenf.es M using ^ " M1 ^"^^ KPBA1 lr om M1 (S5). Atthis point, dev.ee 

M device A is an unauthorized dm ^S^StSSS!^ B involves steps S6 through S11 . It shoukf 
Bhasauthenti M teddeviceATheprocess^^ 

rrr^ e r a ?d^ 
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KPVB was created within the secure section of device B and never needed to be disclosed outside that secure section. 
KPVB 1 is used in a later step to generate the shared secret. Device B creates two messages, M3 and M4, and sends 
those messages to device A (S7). Message M3 contains ID B and KPBB1, signed by KPVB. Once device A receives 
M3 and M4, device A verifies-M4 using KPBSIGM, the manufacturer public signing key (S8). If M4 does not verify, 

5 device A stops the process and assumes that device B is an unauthorized device. Device A then extracts KPBB from 
M4 (S9). KPBB is the public part of the key of which KPVB is the private part, which is included in MCer^. At this point, 
device A is reasonably assured that KPBB is in fact the public part of the key, because the manufacturer certified it. 
[0053] At step S1 0, device A verifies M3 using KPBB. If M3 does not verify, device A stops the process and assumes 
that device B is an unauthorized device. If M3 does verify, device A extracts KPBB1 from M3 (S11 ). At this point, device 

10 A has authenticated device B and device B has authenticated device A. Furthermore, at this point, device A ontains 
KPVA1 and KPBB1 and device B contains KPVB1 and KPBA1 . With each of these two values, each device can generate 
the shared secret. Once each device generates the shared secret, the two devices can communicate between them- 
selves securely, by using the shared secret (S1 2A, S1 2B). One method of generating such a shared secret is described 
below, but other methods could be used to generate the shared secret. In some systems, it may be preferred to generate 

15 a shared secret that does not rely on the security of KPBSIGM, so that the operator's system is not compromised after 
a compromise of KPBSIGM. 

[0054] One method of generating a shared secret is a Diffee-Hellman (DH) exchange. A DH exchange uses two 
variables, a and n, that may or may not be secret and where a < n. Device A generates its key pair such that KPBA1 
= a KPVA1 mod n and device B generates its key pair such that KPBB1 = <x KPVB1 mod n. Once device A extracts KPBB1 
20 from M3, device A can calculate Y A = KPBB1 KPVA1 mod n and once device B extracts KPBA1 from Ml, device B can 
calculate Y B = KPBA1 KPVB1 mod n. However, because of the way those values were generated: 



25 



30 



Y K ~ KPBB mod n 

= (a KPVBl ) KPVAl modn 
= (a KPVAl ) KPVBl modn 

= KPBAl ICPVBl modn 



and therefore, since Y A = Y B , and performing discrete logarithms is difficult, devices A and B have a shared secret. In 
35 a particular embodiment, n is a large prime number (on the order of 1024 bits) and a is an element of a finite field 
having 2* elements where q is a 160-bit prime that divides r>1 and a. If Y = Y A = Y B is one the order of 1024 bits, 
several keys can be created from Y, such as 56-bit DES keys. There are many different uses for the shared secret 
once it is created. 

[0055] Fig. 3 shows some details of the data values stored in storage 34. In a more detailed implementation, storage 
40 34 contains storage for the elements shown in Table 1 . 







TABLE 1. 




Element 


Description 


45 


Version Number 


The version of the protocol used by the terminal to set up secure channels and/or exchange 
keys. 




SSID 


A manufacturer assigned value unique to a specific terminal/target SS. 


50 


Permissions Flags 


Flags indicating which actions are allowed. 




Key Loading Type 


The type of key loading that occurs in the initial autokey loading process. Examples: key 
exchange key, temporary superkey, terminal key loading key. 


55 


KSS 


Key pair for the terminal (KPVSS, KPBSS). 




KPBSIGM 


Public portion of manufacturer's signature key. 
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TABLE 1 . (continued) 



Element 



MCert 



Description 



Manufacturer Certificate: a signature of KSS using the ^acturer key pacific > to 
operator of the target SS. The data signed includes the Vers.on Number. SSID, Perm.ss.on 



Flags and KSS 
Check Digits 



^S. requested by the operator. The permissions flags might, for example, ,nd,cate. 



a. If MFKs can be shared among multiple security modules 

b. If the terminal is allowed to load other MFKs 
c Load terminals with application programs. 

d. If the terminal is allowed to load key exchange keys (KEKs). 

e. If the terminal is allowed to load specific terminal keys. 

f . If DSA signatures are to be verified. 



.s.p,,,.. „c,*y .nod* r„n„,Mu,., .«« «2£l^™»»™<»»» l "«»» l » , » m 
loan ATM,b»l»<noula.«cur«yn«xl"» AseouolyrnaJu ™«" P m 6us „. 

comzsuon would mod to *" "™~ i e ^„ , w oooodl, .oodul.s. 10. organization oar, 

opera or, * terminal into terminal database 1 54. 

operator can add the SSID ana wioen ror edu. new ^ arfrtrmoH hv thP <;ecuritv module 24' within key server 

«,e oubnatwoolo Sac.my mod* 24' ban be 0» « . i -o» V ™d* * «» 
(MFK's) and read data from the secure section in a secure manner. 
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[0063] In the manner described above, a terminal and a key server, or two terminals, can connect securely over an 
insecure channel, where neither data integrity nor data confidentiality is assured, and securely pass messages and 
verify the authority of the other party to a conversation. This allows two terminals to communicate messages between 
themselves, set up shared secrets, or to coordinate secure loading of keys over the insecure channel. For example, 

5 once the process shown in Fig. 5 is complete, the key server can securely transmit a new set of keys or a "key change" 
command to an SS and that SS can verify that the key server is what it claims to be before changing keys. 
[0064] To prevent someone from undetectably inserting an unauthorized device into a network and having it verified 
by a key server, the key server maintains audit log 156 of the terminals with which the key server has performed. A 
record in audit log 156 contains the manufacturer-generated ID for the terminal (SSID) and a sequential record number. 

10 The sequential record numbers make deletions of records from audit log 156 apparent. The records can be signed to 
prevent alteration. 

[0065] A system for loading an initial set of one or more keys without needing a secure channel to load the initial set 
of keys has now been described. With this system, secure sections can be securely initialized and authenticated over 
insecure networks. 

15 [0066] The above description is illustrative and not restrictive. Many variations of the invention will become apparent 
to those of skill in the art upon review of this disclosure. The scope of the invention should, therefore, be determined 
not with reference to the'above description, but instead should be determined with reference to the appended claims 
along with their full scope of equivalents. 

20 

Claims 

1 . A method of manufacturing a device for use by an operator for communicating with other devices operated for the 
operator, wherein a manufacturer has a manufacturer key that is normally unavailable to others besides the man- 

25 ufacturer and its authorized agents and the communication is over an untrusted channel that is not assumed to 

be secure from eavesdropping or message modification, the method comprising the steps of: 

manufacturing the device to include a secure section such that the secure section need not contain a secret 
of the operator, the secure section being circuitry that is enclosed within a tamper-resistant boundary; 
30 initializing the device with a device identifier unique to that device; 

triggering the secure section to generate an internal secret; 

creating, within the secure section, an irreversible cryptographic transform of the internal secret; 
outputting, from the device, the irreversible cryptographic transform as a public part of the internal secret; and 
generating a digital signature of the public part and the device identifier using the manufacturer key. 

35 

2. The method of claim 1 , wherein each device is manufactured as a generic device not specific to a particular operator 
or network onto which the device may be connected. 

3. The method of claim 1 , further comprising a step of certifying the device as being a properly manufactured device. 

40 

.. 4. The method of claim 1 , wherein the step of creating the irreversible cryptographic transform comprises a step of 
generating a public key pair where the public part of the internal secret is a public key portion of the public key pair. 

% - 5. Using a device having an internal secret for which a digital signature of a public part of the internal secret and a 
45 - unique device identifier using the manufacturer key exists, a method of setting up a secure channel between the 
device and a key server over an untrusted channel, the method comprising the steps of: 

authenticating the key server to the device; 

authenticating the device to the key server by requiring the device to provide a response to a challenge where 
50 : the response is such that only a device knowing the internal secret could feasibly generate the response; 

creating a shared secret shared by the key server and the device using information provided by the key server 

and the device in the steps of authenticating; and . 

using the shared secret for secure communications over the channel. 

55 6. The method of claim 5, wherein the step of using the shared secret comprises at least one of transferring data 
between the key server and the device, transferring a key between the key server and the device, setting a con- 
figuration value in the device, or reading configuration values from the device. 
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untrusted entity, the method comprising the steps of: 
and lh« Israel d.vic. is .<«imsdlo eoal.ii no 

a m _ «~ - — * •«•• - • k " — '° " °~ 

channel, the secure key loading system compnsmg: 

a secure chip within target device, the secure chip comprising: 

(a) a random number generator, 

(b) an exponentiator; and random number generator and the expo- 
manufactured state; and 

a -» .-»«.««="«•- ~»* — "™" ha,< '™ a "' * 

Sons channel established using the generated secret key. 
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